IBIS Macromodel Task Group Meeting date: 16 May 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora Systems: Dian Yang Cadence Design Systems: * Ambrish Varma * Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai * Chi-te Chen Liwei Zhao Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz * Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Arpad: Send an email announcing the straw poll ATM vote on whether to include SPIM in the IBIS specification itself or make it a stand-alone specification. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 9th meeting. Michael moved to approve the minutes. Graham seconded the motion. There were no objections. -------------- New Discussion: Agenda Item 8: Multi-level analog buffer modeling Arpad noted that he had introduced this discussion topic. He said there seemed to be no immediate need to do anything about it. Arpad moved to table it. Walter seconded. There were no objections. SPIM (BIRD223) in IBIS or as a separate document/specification: Arpad opened the discussion and asked for comments in advance of the scheduled straw poll. Michael asked if there was some particular reason we would want to separate SPIM from IBIS. He said that he had the impression that SPIM was of interest to anyone wanting to do power-aware analysis. Why would we need to make it a separate document? Walter said that there are many different types of models for PI and different techniques for PI analysis. He asked whether we were going to include all of them in the IBIS specification, or whether we are sure that SPIM is the right one. If we agree that it's the right one, then go ahead and put it in the IBIS specification. Walter said that we had thus far only heard from a couple of organizations in favor of SPIM. Ambrish said that his organization was also in favor of SPIM. Walter said he had no objection if EDA companies who do PI agree that SPIM is a good way to do it. Arpad agreed that there are different ways to handle PI. He said his question revolved around the word "technique". He said he thought we should be careful to focus on what goes into the model, not on telling EDA tools how to use the model. He noted Walter's example of Touchstone as an independent specification that IBIS utilized. He said Touchstone models could be useful for SI and PI modeling, but he noted that Touchstone is a modeling specification that describes what goes into a model not how an EDA tool should use it. Arpad agreed that the AMI sections of IBIS describe simulation flows, which Ambrish had pointed out as a counter example, but he said he thought IBIS was better off avoiding flow descriptions. Walter agreed that it's important to provide the derivation discussions for what goes into the model itself. For example, how do you create the [Model], how do you measure the I/V curve data in a lab or via simulation with your digital twin model of the device? Arpad returned to Michael's original question about why we might choose to separate SPIM from IBIS. He said one consideration might be logistical. He said the IBIS specification is getting rather large, in excess of 400 pages. It's becoming a bit cumbersome to maintain. Michael said that together vs. separate involved a tradeoff between different sets of maintenance headaches, which were roughly equivalent. We have some editorial issues adding SPIM to IBIS and making IBIS larger, but if we keep them separate then we create different issues with tracking and syncing different versions of the two documents. Bob said that he was in favor of integrating SPIM in IBIS. He acknowledged that it will make IBIS larger, but he said the syntax is very similar to existing IBIS syntax. He said we could simply add a -spim flag and add support for SPIM to the existing ibischk parser. He agreed with Michael that tracking two separate documents has its own set of challenges. He said SPIM could be added as a new chapter in IBIS. Curtis said he thought one practical reason for keeping SPIM inside IBIS is that we want to get as much feedback on the proposal (BIRD223) as possible. He said his concern was that if we decided up front to make SPIM a separate document, we might be less likely to get careful review and feedback from other organizations. Ambrish agreed. Arpad said this was an interesting point, and he wondered whether we would have to consider creating a new task group if it were to be a separate document, e.g., a power integrity task group. Michael suggested that a separate task group for PI might give the topic the attention that it deserves. Graham agreed and said that the variety of topics and solutions under the umbrella of PI could justify a separate task group. He noted that we still tend to talk about SI and PI separately as opposed to overall system analysis, though he agreed that SI/PI cosimulation can be important. He said he had no real preference for whether SPIM was separate or part of IBIS, but he thought a new PI task group would be useful in either case. Arpad said Graham's comments were an interesting way to think about it. He said you can do PI on its own without much signal information. You can also do SI/PI combined and see how they affect each other, primarily how the power affects the signal. He said in IBIS we have power-aware buffer models ([Composite Current], [ISSO_PU], [ISSO_PD], etc.), and we have Touchstone models, which could be made for SI and PI separately or could combine both. So, he wondered if it was a question of whether we want to keep SI and PI separate. If we want to combine them, then it probably makes sense to have SPIM in IBIS. Ambrish agreed that the question is whether we want an overall power-aware IBIS model that can be used for SI/PI. Arpad and Ambrish agreed that this is probably the goal, and in that case it would make sense to keep SPIM in IBIS. Randy said he was torn on the direction we should take. He thought that we could make it work either way. He agreed that making SPIM a separate document might result in a lack of focus and a loss of feedback. He agreed that PI is a big enough topic that it could justify its own task group, but he said it might be hard to start another weekly meeting. He said perhaps ATM has the time to focus on PI issues for now. Arpad asked if any more discussion was required prior to the straw poll. Arpad started the straw poll vote by organization. The question was whether to keep on the course of having SPIM be part of the IBIS specification. The votes were as follows: Ansys - Yes Cadence - Yes Intel - Yes Mathworks - Abstain Siemens EDA - Abstain Teraspeed - Yes Zuken - Yes The total was 5 Yes votes and 2 Abstain votes, and the ATM recommends keeping SPIM as part of IBIS rather than a separate document. PSIJ Sensitivity: Bob noted that a group from India Institute of Technology Jodhpur had given a presentation on PSIJ in CMOS inverters at the recent IEEE SPI IBIS Summit. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibis.org_summits_may23_verma.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=k0Ad7uasXdJEdmanOUk0fMdMhleBBaoXCmkmeHqRe8UT-5jLFZgwHO3rk-UsI5zp&s=ODQoXvI4QvU0i22brrHsGAA-V7gKufs9qS5JpmaQu_A&e= Bob said that their presentation was not related to Kinger's PSIJ Sensitivity proposal and did not discuss the existing BIRD220 "Pre-driver PSIJ Sensitivity Keyword". However, Bob said he had forwarded the group information on both PSIJ proposals to see if they were interested in commenting. - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. New ARs: Arpad: Send an email announcing the ATM task group's recommendation that SPIM continue on the track toward being included in IBIS. ------------- Next meeting: 23 May 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives